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Abstract 
This document specifies the payload format for packetization of 
Global System for Mobile Communications Half Rate (GSM-HR) speech 
codec data into the Real-time Transport Protocol (RTP). The payload 
format supports transmission of multiple frames per payload and 
packet loss robustness methods using redundancy. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5993. 
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Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


This document specifies the payload format for packetization of GSM 
Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the 
Real-time Transport Protocol (RTP) [RFC3550]. The payload format 
supports transmission of multiple frames per payload and packet loss 
robustness methods using redundancy. 


This document starts with conventions, a brief description of the 
codec, and payload format capabilities. The payload format is 
specified in Section 5. Examples can be found in Section 6. The 
media type specification and its mappings to SDP, and considerations 
when using the Session Description Protocol (SDP) offer/answer 
procedures are then specified. The document ends with considerations 
related to congestion control and security. 


This document registers a media type (audio/GSM-HR-08) for the Real- 
time Transport Protocol (RTP) payload format for the GSM-HR codec. 
Note: This format is not compatible with the one provided back in 
1999 to 2000 in early draft versions of what was later published as 
RFC 3551. RFC 3551 was based on a later version of the Audio-Visual 
Profile (AVP) draft, which did not provide any specification of the 
GSM-HR payload format. To avoid a possible conflict with this older 
format, the media type of the payload format specified in this 
document has a media type name that is different from (audio/GSM-HR). 


Conventions Used in This Document 


This document uses the normal IETF bit-order representation. Bit 
fields in figures are read left to right and then down. The leftmost 
bit in each field is the most significant. The numbering starts from 
O0 and ascends, where bit 0 will be the most significant. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


GSM Half Rate 


The Global System for Mobile Communications (GSM) network provides 
with mobile communication services for nearly 3 billion users 
(statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of 
the speech codecs used in GSM networks.  GSM-HR denotes the Half Rate 
Speech codec as specified in [TS46.002]. 


Note: For historical reasons, these 46-series specifications are 
internally referenced as 06-series. A simple mapping applies; for 
example, 46.020 is referenced as 06.20, and so on. 
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The GSM-HR codec has a frame length of 20 ms, with narrowband speech 
sampled at 8000 Hz, i.e., 160 samples per frame. Each speech frame 
is compressed into 112 bits of speech parameters, which is equivalent 
to a bit rate of 5.6 kbit/s. Speech pauses are detected by a 
standardized Voice Activity Detection (VAD). During speech pauses, 
the transmission of speech frames is inhibited. Silence Descriptor 
(SID) frames are transmitted at the end of a talkspurt and about 
every 480 ms during speech pauses to allow for a decent comfort noise 
(CN) quality on the receiver side. 


The SID frame generation in the GSM radio network is determined by 
the GSM mobile station and the GSM radio subsystem.  SID frames come 
during speech pauses in the uplink from the mobile station about 
every 480 ms. In the downlink to the mobile station, when they are 
generated by the encoder of the GSM radio subsystem, SID frames are 
sent every 20 ms to the GSM base station, which then picks only one 
every 480 ms for downlink radio transmission. For other 
applications, like transport over IP, it is more appropriate to send 
the SID frames less often than every 20 ms, but 480 ms may be too 
sparse. We recommend as a compromise that a GSM-HR encoder outside 
of the GSM radio network (i.e., not in the GSM mobile station and not 
in the GSM radio subsystem, but, for example, in the media gateway of 
the core network) should generate and send SID frames every 160 ms. 


4. Payload Format Capabilities 


This RTP payload format carries one or more GSM-HR encoded frames -- 
either full voice or silence descriptor (SID) -- representing a mono 
Speech signal. To maintain synchronization or to indicate unsent or 
lost frames, it has the capability to indicate No Data frames. 


4.1. Use of Forward Error Correction (FEC) 


Generic forward error correction within RTP is defined, for example, 
in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC 
2198 [RFC2198]. Either scheme can be used to add redundant 
information to the RTP packet stream and make it more resilient to 
packet losses, at the expense of a higher bit rate. Please see 
either RFC for a discussion of the implications of the higher bit 
rate to network congestion. 


In addition to these media-unaware mechanisms, this memo specifies an 
optional-to-use GSM-HR-specific form of audio redundancy coding, 
which may be beneficial in terms of packetization overhead. 
Conceptually, previously transmitted transport frames are aggregated 
together with new ones. A sliding window can be used to group the 
frames to be sent in each payload. Figure 1 below shows an example. 
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-—4-------- 4-------- 4p-------- +-------- +-------- +-------- +-------- +-- 
| £(n-2) | £(n-1) | £n) | £(n*1) | f£(n+2) | £(n*3) | £(n+4) | 
-—4-------- +-------- +-------- +-------- +-------- +-------- 4+-------- +-- 

<---- p(n-1) ----> 
<----- p(n) ----- > 
Kec spun) 2-22 
«---- p(n*2) ----» 
«---- p(n*3) ----» 
«c--— pinta) ---—-» 


Figure 1: An Example of Redundant Transmission 


Here, each frame is retransmitted once in the following RTP payload 
packet. f(n-2)...f(n+4) denote a sequence of audio frames, and 
p(n-1)...p(n*4) a sequence of payload packets. 


The mechanism described does not really require signaling at the 
session setup. However, signaling has been defined to allow the 
sender to voluntarily bound the buffering and delay requirements. If 
nothing is signaled, the use of this mechanism is allowed and 
unbounded. For a certain timestamp, the receiver may acquire 
multiple copies of a frame containing encoded audio data. The cost 
of this scheme is bandwidth, and the receiver delay is necessary to 
allow the redundant copy to arrive. 


This redundancy scheme provides a functionality similar to the one 
described in RFC 2198, but it works only if both original frames and 
redundant representations are GSM-HR frames. When the use of other 
media coding schemes is desirable, one has to resort to RFC 2198. 


The sender is responsible for selecting an appropriate amount of 
redundancy, based on feedback regarding the channel conditions, e.g., 
in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The 
sender is also responsible for avoiding congestion, which may be 
exacerbated by redundancy (see Section 9 for more details). 


5. Payload Format 


The format of the RTP header is specified in [RFC3550]. The payload 
format described in this document uses the header fields in a manner 
consistent with that specification. 


The duration of one speech frame is 20 ms. The sampling frequency is 
8000 Hz, corresponding to 160 speech samples per frame. An RTP 
packet may contain multiple frames of encoded speech or SID 
parameters. Each packet covers a period of one or more contiguous 
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20-ms frame intervals. During silence periods, no speech packets are 
sent; however, SID packets are transmitted every now and then. 


To allow for error resiliency through redundant transmission, the 
periods covered by multiple packets MAY overlap in time. A receiver 
MUST be prepared to receive any speech frame multiple times. A given 
frame MUST NOT be encoded as a speech frame in one packet and as a 
SID frame or as a No Data frame in another packet. Furthermore, a 
given frame MUST NOT be encoded with different voicing modes in 
different packets. 


The rules regarding maximum payload size given in Section 3.2 of 
[RFC5405] SHOULD be followed. 


5.1. RIP Header Usage 


The RTP timestamp corresponds to the sampling instant of the first 
sample encoded for the first frame in the packet. The timestamp 
clock frequency SHALL be 8000 Hz. The timestamp is also used to 
recover the correct decoding order of the frames. 


The RTP header marker bit (M) SHALL be set to 1 whenever the first 
frame carried in the packet is the first frame in a talkspurt (see 
definition of the talkspurt in Section 4.1 of [RFC3551]). For all 
other packets, the marker bit SHALL be set to zero (M-0). 


The assignment of an RTP payload type for the format defined in this 
memo is outside the scope of this document. The RTP profiles in use 
currently mandate binding the payload type dynamically for this 
payload format. 


The remaining RTP header fields are used as specified in RFC 3550 
[RFC3550]. 


5.2. Payload Structure 
The complete payload consists of a payload table of contents (ToC) 
section, followed by speech data representing one or more speech 
frames, SID frames, or No Data frames. The following diagram shows 
the general payload format layout: 
PaaS SS SSeS q-ee-—-———--—-——2---———-—-——-——- 


| ToC section | speech data section 
4R-——---------- 4-——--—-------------------- 


Figure 2: General Payload Format Layout 
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Each ToC element is one octet and corresponds to one speech frame; 
the number of ToC elements is thus equal to the number of speech 
frames (including SID frames and No Data frames). Each ToC entry 
represents a consecutive speech or SID or No Data frame. The 
timestamp value for ToC element (and corresponding speech frame data) 
N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32. 
The format of the ToC element is as follows. 


01234567 
+-+-+-+-+-+-+-+-+ 
|F| FT |RRRR| 
+-+-+-+-+-+-+-+-+ 


Figure 3: The TOC Element 


F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes 
the last ToC element. 


R: Reserved bits; MUST be set to zero, and MUST be ignored by 
receiver. 


FT: Frame type 
000 = Good Speech frame 
001 = Reserved 
010 = Good SID frame 
011 = Reserved 
100 = Reserved 
101 = Reserved 
110 = Reserved 
111 = No_Data frame 


The length of the payload data depends on the frame type: 
Good Speech frame: The 112 speech data bits are put in 14 octets. 


Good SID frame: The 33 SID data bits are put in 14 octets, as in 
the case of Speech frames, with the unused 79 bits all set to "1". 


No_Data frame: Length of payload data is zero octets. 


Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad 
SID frame", or "No_Data frame" are not sent in RTP packets, in order 
to save bandwidth. They are marked as "No_Data frame", if they occur 
within an RTP packet that carries more than one speech frame, SID 
frame, or No_Data frame. 
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5.2.1. Encoding of Speech Frames 


The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS 
46.020, Annex B [TS46.020], in their order of occurrence. The first 
bit (b1) of the first parameter is placed in the most significant bit 
(MSB) (bit 0) of the first octet (octet 1) of the payload field; the 
second bit is placed in bit 1 of the first octet; and so on. The 
last bit (b112) is placed in the least significant bit (LSB) (bit 7) 
of octet 14. 


5.2.2. Encoding of Silence Description Frames 


The GSM-HR codec applies a specific coding for silence periods in so- 
called SID frames. The coding of SID frames is based on the coding 
of speech frames by using only the first 33 bits for SID parameters 
and by setting all of the remaining 79 bits to "1". 


5.3. Implementation Considerations 


An application implementing this payload format MUST understand all 
the payload parameters that are defined in this specification. Any 
mapping of the parameters to a signaling protocol MUST support all 
parameters. So an implementation of this payload format in an 
application using SDP is required to understand all the payload 
parameters in their SDP-mapped form. This requirement ensures that 
an implementation always can decide whether it is capable of 
communicating when the communicating entities support this version of 
the specification. 


5.3.1. Transmission of SID Frames 
When using this RTP payload format, the sender SHOULD generate and 
send SID frames every 160 ms, i.e., every 8th frame, during silent 
periods. Other SID transmission intervals may occur due to gateways 
to other systems that use other transmission intervals. 

5.3.2. Receiving Redundant Frames 
The reception of redundant audio frames, i.e., more than one audio 


frame from the same source for the same time slot, MUST be supported 
by the implementation. 
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5.3.3. Decoding Validation 


If the receiver finds a mismatch between the 
payload and the size indicated by the Toc of 
receiver SHOULD discard the packet. This is 
decoding a frame parsed from a payload based 
could severely degrade the audio quality. 
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6. Examples 


A few examples below highlight the payload format. 


6.1. 


3 Frames 


Below is a basic example of the aggregation of 3 consecutive speech 
frames into a single packet. 


Duan, 


The first 24 bits are ToC elements. 


Bit 0 is '1', as another ToC element follows. 
Bits 1..3 are 000 = Good speech frame 

Bits 4..7 are 0000 = Reserved 

Bit 8 is '1', as another ToC element follows. 
Bits 9..11 are 000 = Good speech frame 

Bits 12..15 are 0000 = Reserved 

Bit 16 is '0'; no more ToC elements follow. 
Bits 17..19 are 000 = Good speech frame 

Bits 20..23 are 0000 = Reserved 


0 1 2 3 
0123456789 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|ıļlo 0 oļo 0 o 0]1]00 0]00 0 oļoļo o ojo 0 o oļb1 b8 | 
T—t-—t-—t-—t-—t-—k--t-—t-t-t-t-t-t-t-t-t-t-t-t-t-t-t- t 
|b9 Frame 1 b40| 
+ + 
|b41 b72 | 
+ + 
|b73 b104 | 
+ t—+-+-4+-+-4-4-4+-4-4-4+-4+-4+-4-4+-4+-4-4-4+-4-4-4+-4+-4-4+ 
[5105 b112|b1 24 | 
+-+-+-+-+-+-+-+-+ + 
|b25 Frame 2 b56 | 
+ + 
| b57 588 | 
4 +-+-+-+-+-+-+-+-+ 
[589 b112|bp1 b8 | 
T—t-—L—t-—t-—t-—k--t-—t-t-t-t-t-t-t-t-t-t-t-t-t-t-t- t 
[59 Frame 3 540 | 
t t 
|b41 b72 | 
+ + 
|b73 b104 | 
+ T—t-—t—t-—t-—t-—t--t-—t--—t-k-t-t-t-t-t-t-t-t-t-t-t- 
[5105 b112 | 


+-+-+-+-+-+-+-+-+ 
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7. 


Duan, 


3 Frames with Lost Frame in the Middle 


Below is an example of a payload carrying 3 frames, where the middle 
one is No Data (for example, due to loss prior to transmission by the 
RTP source). 


The first 24 bits are ToC elements. 


Bit 0 is '1', as another ToC element follows. 
Bits 1..3 are 000 = Good speech frame 

Bits 4..7 are 0000 = Reserved 

Bit 8 is '1', as another ToC element follows. 
Bits 9..11 are 111 = No Data frame 

Bits 12..15 are 0000 = Reserved 

Bit 16 is '0'; no more ToC elements follow. 
Bits 17..19 are 000 = Good speech frame 

Bits 20..23 are 0000 = Reserved 


0 1 2 3 
OL 2 3 456 7:8:9 0 1.2 3 456.7 8-9 0.1 2 3 4 5 6 7-8.9-0 4 
C — ———— E 


|: por-g axo: 0 0 os Psp Y pg: Or gere T6779 29-0: 0: bs b8 | 
T—t-—t—t-—t-—t-—k-t-—t-—t-t-t-t-t-t-t-t-t-t-t-t-t-t-t- t 
|b9 Frame 1 b40| 
+ + 
|b41 b72 | 
+ + 
|b73 b104 | 
+ T—t-—t—t-—-—t—k-t-t-—t--—t-t-t-t-t-t-t-t-t-t-t-t-t-t 
[5105 b112|b1 24 | 
+-+-+-+-+-+-+-+-+ + 
|b25 Frame 3 b56| 
+ + 
|b57 b88 | 
+ +-+-+-+-+-+-+-+-+ 
[589 b112 | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Payload Format Parameters 


This RTP payload format is identified using the media type "audio/ 
GSM-HR-08", which is registered in accordance with [RFC4855] and uses 
[RFC4288] as a template. Note: Media subtype names are case- 
insensitive. 
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7.1. Media Type Definition 

The media type for the GSM-HR codec is allocated from the IETF tree, 

Since GSM-HR is a well-known speech codec. This media type 

registration covers real-time transfer via RTP. 

Note: Reception of any unspecified parameter MUST be ignored by the 

receiver to ensure that additional parameters can be added in the 

future. 

Type name: audio 

Subtype name: GSM-HR-08 

Required parameters: none 

Optional parameters: 
max-red: The maximum duration in milliseconds that elapses between 
the primary (first) transmission of a frame and any redundant 
transmission that the sender will use. This parameter allows a 
receiver to have a bounded delay when redundancy is used. Allowed 
values are integers between 0 (no redundancy will be used) and 
65535. If the parameter is omitted, no limitation on the use of 
redundancy is present. 
ptime: See [RFC4566]. 
maxptime: See [RFC4566]. 


Encoding considerations: 


This media type is framed and binary; see Section 4.8 of RFC 4288 
[RFC4288]. 


Security considerations: 
See Section 10 of RFC 5993. 
Interoperability considerations: 
The media subtype name contains "-08" to avoid potential conflict 


with any earlier drafts of GSM-HR RTP payload types that aren't 
bit-compatible. 
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Published specifications: 
RFC 5993, 3GPP TS 46.002 
Applications that use this media type: 


Real-time audio applications like voice over IP and 
teleconference. 


Additional information: none 
Person & email address to contact for further information: 
Ingemar Johansson <ingemar.s.johansson@ericsson.com> 
Intended usage: COMMON 
Restrictions on usage: 
This media type depends on RTP framing, and hence is only defined 
for transfer via RTP [RFC3550]. Transport within other framing 
protocols is not defined at this time. 
Authors: 
Xiaodong Duan <duanxiaodong@chinamobile.com> 
Shuaiyu Wang <wangshuaiyu@chinamobile.com> 
Magnus Westerlund <magnus.westerlund@ericsson.com> 
Ingemar Johansson <ingemar.s.johansson@ericsson.com> 
Karl Hellwig <karl.hellwig@ericsson.com> 
Change controller: 
IETF Audio/Video Transport working group, delegated from the IESG. 
7.2. Mapping to SDP 
The information carried in the media type specification has a 
specific mapping to fields in the Session Description Protocol (SDP) 
[RFC4566], which is commonly used to describe RTP sessions. When SDP 
is used to specify sessions employing the GSM-HR codec, the mapping 


is as follows: 


o The media type ("audio") goes in SDP "m=" as the media name. 
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o The media subtype (payload format name) goes in SDP "a-rtpmap" as 
the encoding name. The RTP clock rate in "a-rtpmap" MUST be 8000, 
and the encoding parameters (number of channels) MUST either be 
explicitly set to 1 or omitted, implying a default value of 1. 


o The parameters "ptime" and "maxptime" go in the SDP "a-ptime" and 
"a=maxptime" attributes, respectively. 


o Any remaining parameters go in the SDP "a=fmtp" attribute by 
copying them directly from the media type parameter string as a 
semicolon-separated list of parameter=value pairs. 


7.2.1. Offer/Answer Considerations 


The following considerations apply when using SDP offer/answer 
procedures to negotiate the use of GSM-HR payload in RTP: 


o The SDP offerer and answerer MUST generate GSM-HR packets as 
described by the offered parameters. 


o In most cases, the parameters "maxptime" and "ptime" will not 
affect interoperability; however, the setting of the parameters 
can affect the performance of the application. The SDP offer/ 
answer handling of the "ptime" parameter is described in 
[RFC3264]. The "maxptime" parameter MUST be handled in the same 
way. 


o The parameter "max-red" is a stream property parameter. For 
sendonly or sendrecv unicast media streams, the parameter declares 
the limitation on redundancy that the stream sender will use. For 
recvonly streams, it indicates the desired value for the stream 
sent to the receiver. The answerer MAY change the value, but is 
RECOMMENDED to use the same limitation as the offer declares. In 
the case of multicast, the offerer MAY declare a limitation; this 
SHALL be answered using the same value. A media sender using this 
payload format is RECOMMENDED to always include the "max-red" 
parameter. This information is likely to simplify the media 
stream handling in the receiver. This is especially true if no 
redundancy will be used, in which case "max-red" is set to 0. 


o Any unknown media type parameter in an offer SHALL be removed in 
the answer. 


7.2.2. Declarative SDP Considerations 
In declarative usage, like SDP in the Real Time Streaming Protocol 


(RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 
[RFC2974], the parameters SHALL be interpreted as follows: 
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8. 


10. 


o The stream property parameter ("max-red") is declarative, and a 
participant MUST follow what is declared for the session. In this 
case, it means that the receiver MUST be prepared to allocate 
buffer memory for the given redundancy. Any transmissions MUST 
NOT use more redundancy than what has been declared. More than 
one configuration may be provided if necessary by declaring 
multiple RTP payload types; however, the number of types should be 
kept small. 


o Any "maxptime" and "ptime" values should be selected with care to 
ensure that the session's participants can achieve reasonable 
performance. 


IANA Considerations 


One media type (audio/GSM-HR-08) has been defined, and it has been 
registered in the media types registry; see Section 7.1. 


Congestion Control 


The general congestion control considerations for transporting RTP 
data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g., 
"RTP/AVP" [RFC3551]. 


The number of frames encapsulated in each RTP payload highly 
influences the overall bandwidth of the RTP stream due to header 
overhead constraints.  Packetizing more frames in each RTP payload 
can reduce the number of packets sent and hence the header overhead, 
at the expense of increased delay and reduced error robustness. If 
forward error correction (FEC) is used, the amount of FEC-induced 
redundancy needs to be regulated such that the use of FEC itself does 
not cause a congestion problem. 


Security Considerations 


RTP packets using the payload format defined in this specification 
are subject to the security considerations discussed in the RTP 
specification [RFC3550], and in any applicable RTP profile. The main 
security considerations for the RTP packet carrying the RTP payload 
format defined within this memo are confidentiality, integrity, and 
Source authenticity. Confidentiality is achieved by encryption of 
the RTP payload, and integrity of the RTP packets through a suitable 
cryptographic integrity protection mechanism. A cryptographic system 
may also allow the authentication of the source of the payload. A 
suitable security mechanism for this RIP payload format should 
provide confidentiality, integrity protection, and at least source 
authentication capable of determining whether or not an RTP packet is 
from a member of the RTP session. 
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Jm 


12. 


Note that the appropriate mechanism to provide security to RTP and 
payloads following this may vary. It is dependent on the 
application, the transport, and the signaling protocol employed. 
Therefore, a single mechanism is not sufficient, although if 
suitable, the usage of the Secure Real-time Transport Protocol (SRTP) 
[RFC3711] is recommended. Other mechanisms that may be used are 
IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g., 
for RTP over TCP), but other alternatives may also exist. 


This RTP payload format and its media decoder do not exhibit any 
significant non-uniformity in the receiver-side computational 
complexity for packet processing, and thus are unlikely to pose a 
denial-of-service threat due to the receipt of pathological data; nor 
does the RTP payload format contain any active content. 
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